Receiving OTP codes via SMS or email are one of the weaker ways to secure your accounts with MFA. Obtaining a code by email or SMS takes away from the "something you have" idea, because there are a variety of ways a hacker could take over your phone number (https://en.wikipedia.org/wiki/SIM_swap_scam) or gain access to your email without having physical access to any of your devices at all. If an unauthorized person gained access to your email, they would be able to use that access to both reset your password and receive the authentication code, giving them full access to your account.

Push notification MFA takes the form of a message being sent to an app on your phone asking you to confirm new account logins. This method is a lot better than SMS or email, since an attacker typically wouldn't be able to get these push notifications without having an already logged-in device, which means they would need to compromise one of your other devices first.

We all make mistakes, and there is the risk that you might accept the login attempt by accident. Push notification login authorizations are typically sent to all your devices at once, widening the availability of the MFA code if you have many devices.

The security of push notification MFA is dependent on both the quality of the app, the server component and the trust of the developer who produces it. Installing an app may also require you to accept invasive privileges that grant access to other data on your device. An individual app also requires that you have a specific app for each service which may not require a password to open, unlike a good TOTP generator app.

TOTP is one of the most common forms of MFA available. When you set up TOTP, you are generally required to scan a QR Code (https://en.wikipedia.org/wiki/QR_code) which establishes a "shared secret (https://en.wikipedia.org/wiki/Shared_secret)" with the service that you intend to use. The shared secret is secured inside the authenticator app's data, and is sometimes protected by a password.

The time-limited code is then derived from the shared secret and the current time. As the code is only valid for a short time, without access to the shared secret, an adversary cannot generate new codes.

If you have a hardware security key with TOTP support (such as a YubiKey with Yubico Authenticator (https://yubico.com/products/yubico-authenticator)), we recommend that you store your "shared secrets" on the hardware. Hardware such as the YubiKey was developed with the intention of making the "shared secret" difficult to extract and copy. A YubiKey is also not connected to the Internet, unlike a phone with a TOTP app.

Unlike WebAuthn, TOTP offers no protection against phishing (https://en.wikipedia.org/wiki/Phishing) or reuse attacks. If an adversary obtains a valid code from you, they may use it as many times as they like until it expires (generally 60 seconds).

An adversary could set up a website to imitate an official service in an attempt to trick you into giving out your username, password and current TOTP code. If the adversary then uses those recorded credentials they may be able to log into the real service and hijack the account.

Although not perfect, TOTP is secure enough for most people, and when Tcf362fhardware security keys are not supported Tcf362fauthenticator apps are still a good option.

The YubiKey stores data on a tamper-resistant solid-state chip which is impossible to access (https://security.stackexchange.com/a/245772) non-destructively without an expensive process and a forensics laboratory.

These keys are generally multi-function and provide a number of methods to authenticate. Below are the most common ones.

Yubico OTP is an authentication protocol typically implemented in hardware security keys. When you decide to use Yubico OTP, the key will generate a public ID, private ID, and a Secret Key which is then uploaded to the Yubico OTP server.

When logging into a website, all you need to do is to physically touch the security key. The security key will emulate a keyboard and print out a one-time password into the password field.

The service will then forward the one-time password to the Yubico OTP server for validation. A counter is incremented both on the key and Yubico's validation server. The OTP can only be used once, and when a successful authentication occurs, the counter is increased which prevents reuse of the OTP. Yubico provides a detailed document (https://developers.yubico.com/OTP/OTPs_Explained.html) about the process.

There are some benefits and disadvantages to using Yubico OTP when compared to TOTP.

The Yubico validation server is a cloud based service, and you're placing trust in Yubico that they are storing data securely and not profiling you. The public ID associated with Yubico OTP is reused on every website and could be another avenue for third-parties to profile you. Like TOTP, Yubico OTP does not provide phishing resistance.

If your threat model requires you to have different identities on different websites, do not use Yubico OTP with the same hardware security key across those websites as public ID is unique to each security key.

FIDO (https://en.wikipedia.org/wiki/FIDO_Alliance) includes a number of standards, first there was U2F (https://en.wikipedia.org/wiki/Universal_2nd_Factor) and then later FIDO2 (https://en.wikipedia.org/wiki/FIDO2_Project) which includes the web standard WebAuthn (https://en.wikipedia.org/wiki/WebAuthn).

U2F and FIDO2 refer to the Client to Authenticator Protocol (https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol), which is the protocol between the security key and the computer, such as a laptop or phone. It complements WebAuthn which is the component used to authenticate with the website (the "Relying Party") you're trying to log in on.

WebAuthn is the most secure and private form of second factor authentication. While the authentication experience is similar to Yubico OTP, the key does not print out a one-time password and validate with a third-party server. Instead, it uses public key cryptography (https://en.wikipedia.org/wiki/Public-key_cryptography) for authentication.

When you create an account, the public key is sent to the service, then when you log in, the service will require you to "sign" some data with your private key. The benefit of this is that no password data is ever stored by the service, so there is nothing for an adversary to steal.

This presentation discusses the history of password authentication, the pitfalls (such as password reuse), and the standards for FIDO2 and WebAuthn (https://webauthn.guide):

* How FIDO2 and WebAuthn Stop Account Takeovers (https://youtu.be/aMo4ZlWznao) (YouTube)

FIDO2 and WebAuthn have superior security and privacy properties when compared to any MFA methods.

Typically, for web services it is used with WebAuthn which is a part of the W3C recommendations (https://en.wikipedia.org/wiki/World_Wide_Web_Consortium#W3C_recommendation_(REC)). It uses public key authentication and is more secure than shared secrets used in Yubico OTP and TOTP methods, as it includes the origin name (usually, the domain name) during authentication. Attestation is provided to protect you from phishing attacks, as it helps you to determine that you are using the authentic service and not a fake copy.

Unlike Yubico OTP, WebAuthn does not use any public ID, so the key is not identifiable across different websites. It also does not use any third-party cloud server for authentication. All communication is completed between the key and the website you are logging into. FIDO also uses a counter which is incremented upon use in order to prevent session reuse and cloned keys.

If a website or service supports WebAuthn for the authentication, it is highly recommended that you use it over any other form of MFA.

T969389Part 1/2 Tcf362fNext

Tcf362fGuides Home Tcf362fSearch Guides

Tcf362fHome Tcf362fWiki Tcf362fTG Series Tcf362fChat Tcf362fArticles Tcf362fContact

Ta6a49eContent from Privacy Guides (privacyguides.org), commit 0295ab4.

Ta6a49eLicense: CC BY-SA 4.0 - creativecommons.org/licenses/by-sa/4.0